[アップデート]AWS Firewall Managerは、「他のVPCのセキュリティグループIDを参照」するセキュリティグループを自動作成やリソースに適用できるようになりました

はじめに

AWS Firewall Managerは、「他のVPC上のセキュリティグループIDを参照」するセキュリティグループ（以降、SG）を管理できるポリシールールが追加されました。

Firewall Manager は、AWS Organizations内にあるアカウントで、AWS WAFやSGなどの設定を一元的に管理するセキュリティサービスです。

先に用語の説明をします。

Firewall Managerでは、プライマリセキュリティグループとレプリカセキュリティグループの２つが存在します。

• プライマリSG
  • 各アカウントのリソースに割り当てたいSGをプライマリSGとして、Firewall Managerに設定する
  • Firewall Managerで設定したプライマリSG自体は、リソースに割り当てられません。レプリカSGが割り当てられます。
• レプリカSG
  • Firewall Managerによって、プライマリSGと同じ設定内容のSGがコピーされ、レプリカSGとして対象アカウントに自動作成され、リソースに割り当てることもできます。
• Firewall ManagerでのSGの管理機能
  • 対象のアカウント内にレプリカSGを作成したり、リソースに割り当てる
  • SGルールを監査し、準拠していないルールを修正する
  • 未使用および冗長なSGを検出する

下記は、対象のアカウント内のリソースにレプリカSGを適用するイメージ図です。

従来、Firewall ManagerのプライマリSGは、アウトバウンドやインバウンドルールのうち、送信先に「他VPCのSGのIDを参照する」ルールはレプリカSGとして自動作成することはできませんでした。

送信先に「他VPCのSGのIDを参照する」というのは、以下のような設定のことです。

アップデートによって、送信先に「他VPCのSGのIDを参照する」SGもレプリカSGとして、自動作成したり、リソースに割り当てることができるようになりました。

これによって、ピアリング接続された各VPC内の各リソースに割り当てられたSGは、相互参照することができ、導通することができます。また、Firewall ManagerでそのSGを管理できます。

利用例

具体的な使用例を、構成図をもとに説明します。

下記の構成は、アカウントAとBに存在するEC2インスタンス（①と②）が、アカウントBのプロキシサーバー経由でインターネットに出る構成です。

インターネットの出口を1つのVPCに集約させる構成は、よくありますね。

この構成の場合、①と②のEC2インスタンスのSGは、プロキシサーバーのSGのIDを参照し、アウトバウンドルールを許可する設定が必要です。

そのルールが設定されたSGは、本来、アカウントごとに手動で作成する必要がありますが、今回のアップデートによって、Firewall ManagerからプライマリSGを設定すると、各アカウントにレプリカSGが自動作成され、対象のEC2インスタンス（①と②）に自動で割り当てることができます。

下記のイメージです。

メリットとしては、アカウントごとに手動でSGを作成する必要がなくなり、Firewall Managerで一括管理できる点です。修正する際も、プライマリSGのみを修正すれば、全てのレプリカSGに反映されます。

前提条件

Firewall Managerを利用するには、以下を設定する必要があります

• Organizationsに参加する
• Firewall Manager 管理者アカウントを設定する
• Config を有効にする

また、今回は、下記の構成で検証してみるため、以下を事前に設定しました。

• AアカウントをFirewall Managerの管理アカウントにした
• AアカウントとBアカウントともにConfigを有効化
• AアカウントとBアカウントは、ともに同じリージョン（今回は東京リージョン）
• EC2インスタンス3台とも起動済み
• VPCピアリングし、ルートテーブルも反映済み 　

試してみた

以下の内容をやってみました。

1. EC2インスタンスのタグ付け
2. プライマリSGの作成
3. Firewall Managerのセキュリティポリシーの作成
4. EC2インスタンスの導通確認

EC2インスタンスのタグ付け、プライマリSGの作成

EC2のタグ付けとプライマリSG用のSGを作成します。

プロキシサーバー以外の①と②のEC2インスタンスに、タグを付与します。

• キー名：Firewall Manager
• 値：ON

管理アカウントであるアカウントAで、プライマリSGを作成します。

outbound-sgという名前で、以下の設定で作成しました。

-	タイプ	プロトコル	送信先
インバウンド	-	-	-
アウトバウンド	すべてのトラフィック	すべて	プロキシサーバーのSGのID

作成後、アウトバウンドルールを見ると、送信先には、BアカウントID/プロキシサーバーのSGのIDと、BアカウントのアカウントIDも記載されてました。

Firewall Managerのセキュリティポリシーの作成

Firewall ManagerでSGのセキュリティポリシーを作成します。

• サービス：Security group
• ポリシータイプ：Common security groups（共通SG）
• Region：東京リージョン

ポリシールールは、今回のアップデート内容である下記を選択します。

• "Distribute security group references from the primary security group to the security groups created by the policy"
  • プライマリSGからポリシーによって作成されたSGにSG参照を配布する

プライマリSGは、先程作成したoutbound-sgを選択します。

また、ポリシーアクションは、自動修復を選択します。

対象のアカウントは、アカウントAとアカウントBを選択します。

リソースタイプは、EC2インスタンス、リソースタグは、キーFirewall Manager、値ONにします。

先程の自動修復設定によって、対象のタグを付与した①と②のEC2インスタンスに対して、レプリカSGを自動的に割り当ててくれます。

この設定で、セキュリティポリシーを作成します。

数分後、①と②のEC2インスタンスに対して、レプリカSGが自動的に割り当てられました。

下記は、プロキシサーバーと同じアカウントBに存在するEC2インスタンス（②）に割り当てられたレプリカSGです。

FMManagedSecurityGroup..-プライマリSGのID-VPCのIDという名前でした。

アカウントAのEC2インスタンス（①）に割り当てられたレプリカSGです。

VPCピアリング先のEC2インスタンスの導通確認

EC2インスタンス（①と②）からプロキシサーバー（プライベートIP：10.2.139.187）にpingしてみます。

どちらのEC2インスタンスからもプロキシサーバーにpingが通りました。

最後に、セキュリティポリシーを削除します。

セキュリティポリシーを削除すると、レプリカSGもきれいに削除されました。

最後

今回のアップデートでは、Firewall Managerは、他のVPC上のSGのIDを参照するSGを管理できるポリシールールが追加されました。

今回の利用例で示した構成の場合、アカウントごとに手動でSGを作成する必要がなくなり、Firewall Managerで一括管理できる点がうれしいですね。

修正する際も、プライマリSGのみを修正すれば、全てのレプリカSGに反映されますので、運用管理が楽になります。

参考